Skip to main content

Home/ Agilesparks/ Group items tagged people to follow

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Yuval Yeret

Is Design Dead? - 0 views

www.martinfowler.com/...designDead.html

eng-practices-list

shared by Yuval Yeret on 10 Dec 14 - Cached
  • In its common usage, evolutionary design is a disaster. The design ends up being the aggregation of a bunch of ad-hoc tactical decisions, each of which makes the code harder to alter. In many ways you might argue this is no design, certainly it usually leads to a poor design. As Kent puts it, design is there to enable you to keep changing the software easily in the long term. As design deteriorates, so does your ability to make changes effectively. You have the state of software entropy, over time the design gets worse and worse. Not only does this make the software harder to change, it also makes bugs both easier to breed and harder to find and safely kill. This is the "code and fix" nightmare, where the bugs become exponentially more expensive to fix as the project goes on
  • the planned design approach has been around since the 70s, and lots of people have used it. It is better in many ways than code and fix evolutionary design. But it has some faults. The first fault is that it's impossible to think through all the issues that you need to deal with when you are programming. So it's inevitable that when programming you will find things that question the design. However if the designers are done, moved onto another project, what happens? The programmers start coding around the design and entropy sets in. Even if the designer isn't gone, it takes time to sort out the design issues, change the drawings, and then alter the code. There's usually a quicker fix and time pressure. Hence entropy (again).
  • One way to deal with changing requirements is to build flexibility into the design so that you can easily change it as the requirements change. However this requires insight into what kind of changes you expect. A design can be planned to deal with areas of volatility, but while that will help for foreseen requirements changes, it won't help (and can hurt) for unforeseen changes. So you have to understand the requirements well enough to separate the volatile areas, and my observation is that this is very hard. Now some of these requirements problems are due to not understanding requirements clearly enough. So a lot of people focus on requirements engineering processes to get better requirements in the hope that this will prevent the need to change the design later on. But even this direction is one that may not lead to a cure. Many unforeseen requirements changes occur due to changes in the business. Those can't be prevented, however careful your requirements engineering process.
  • ...6 more annotations...
  • The fundamental assumption underlying XP is that it is possible to flatten the change curve enough to make evolutionary design work. This flattening is both enabled by XP and exploited by XP. This is part of the coupling of the XP practices: specifically you can't do those parts of XP that exploit the flattened curve without doing those things that enable the flattening. This is a common source of the controversy over XP. Many people criticize the exploitation without understanding the enabling. Often the criticisms stem from critics' own experience where they didn't do the enabling practices that allow the exploiting practices to work. As a result they got burned and when they see XP they remember the fire.
  • XP's advice is that you not build flexible components and frameworks for the first case that needs that functionality. Let these structures grow as they are needed. If I want a Money class today that handles addition but not multiplication then I build only addition into the Money class. Even if I'm sure I'll need multiplication in the next iteration, and understand how to do it easily, and think it'll be really quick to do, I'll still leave it till that next iteration.
  • You don't want to spend effort adding new capability that won't be needed until a future iteration. And even if the cost is zero, you still don't want to add it because it increases the cost of modification even if it costs nothing to put in. However you can only sensibly behave this way when you are using XP, or a similar technique that lowers the cost of change.
  • My advice to XPers using patterns would be Invest time in learning about patterns Concentrate on when to apply the pattern (not too early) Concentrate on how to implement the pattern in its simplest form first, then add complexity later. If you put a pattern in, and later realize that it isn't pulling its weight - don't be afraid to take it out again.
  • begin by assessing what the likely architecture is. If you see a large amount of data with multiple users, go ahead and use a database from day 1. If you see complex business logic, put in a domain model. However in deference to the gods of YAGNI, when in doubt err on the side of simplicity. Also be ready to simplify your architecture as soon as you see that part of the architecture isn't adding anything.
  • XP design looks for the following skills A constant desire to keep code as clear and simple as possible Refactoring skills so you can confidently make improvements whenever you see the need. A good knowledge of patterns: not just the solutions but also appreciating when to use them and how to evolve into them. Designing with an eye to future changes, knowing that decisions taken now will have to be changed in the future. Knowing how to communicate the design to the people who need to understand it, using code, diagrams and above all: conversation.
Yuval Yeret

Larman's Laws of Organizational Behavior - Craig Larman - 0 views

www.craiglarman.com/...index.php

agile-change-management-list

shared by Yuval Yeret on 08 Jul 14 - No Cached
  • Yuval Yeret on 08 Jul 14
     
    "Larman's Laws of Organizational Behavior After decades of observation and organizational consulting, here are Larman's Laws of Organizational Behavior. These are observations rather than laws to follow ;) 1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and "specialist" positions & power structures. 2. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo. 3. As a corollary to (1), any change initiative will be derided as "purist", "theoretical", and "needing pragmatic customization for local concerns" -- which deflects from addressing weaknesses and manager/specialist status quo. 4. Culture follows structure. i.e., if you want to really change culture, you have to start with changing structure, because culture does not really change otherwise. and that's why deep systems of thought such as organizational learning are not very sticky or impactful by themselves, and why systems such as scrum (that have a strong focus on structural change at the start) tend to more quickly impact culture. i discovered that john seddon also observed this: "Attempting to change an organization's culture is a folly, it always fails. Peoples' behavior (the culture) is a product of the system; when you change the system peoples' behavior changes." "
Yuval Yeret

From the Agile Transformation Trenches: Culture Change with Pigs, not Chickens - 0 views

borland.typepad.com/...ge-with-pigs-not-chickens.html

Agile transition agilesparksblog

shared by Yuval Yeret on 07 Jul 09 - Cached
  • Identify the technical leaders within projects; those that are “self-driven to produce quality results on time … combine technical ability with enough people skills …are trusted and respected by both their managers and fellow developers, are determined to make the team succeed, and usually live the work.” (Chief programmers, Chapter 2:  A Practical Guide to FDD).
  • Sell them the vision: if you cannot sell these people on the benefits to them, their colleagues and the organization of the new way of working then something is wrong
  • Provide in-depth training and on-going coaching. It is better to have a single lead person trained in-depth who can coach his teammates through the basics than to have the whole team trained on the basics with no-one on the team to turn to when the basics are not enough.
  • ...3 more annotations...
  • Providing initial training is simply not enough. When the pressure is on, the temptation to return to previous ways of doing things is often too strong to resist. If technical leads are to work for you, they need on-going support and coaching, and a means by which they can support each other.  Good external coaches (expert chickens?) can help here.
  • Let the technical leads continue working on their projects. Some fail at the final hurdle by doing 1-3 above and then assigning or scheduling the technical leads to coach other projects, effectively turning them from pigs into chickens.
  • To summarize, if you can produce a change in the behavior of the lead pigs, the other pigs will, by definition, follow. However, pigs will not follow chickens for long because chickens are simply not pigs.
  • Yuval Yeret on 07 Jul 09
     
    Last month David Anderson wrote a two-part article on why agile transformation initiatives fail. David's suggestion to concentrate on cultural change reminded me of one of my favorite bits on process initiatives. From Peter Coad's book, Java Modeling in Color...
Yuval Yeret

Ambler - Doing RFPs the Agile way - 0 views

www.ddj.com/...218101915

agile contracts agile-contracts-list

shared by Yuval Yeret on 02 Jul 09 - Cached
  • RFPs the Agile Way -- or -- Fear and Loathing in the Procurement Department
Yuval Yeret

How to make a LOT more money using agile - 0 views

www.agileforall.com/...e-a-lot-more-money-using-agile

agile roi agile-roi

shared by Yuval Yeret on 04 Jun 09 - Cached
  • How to make a LOT more money using agile
  • More frequent releases
  • expectations must be set for releases to be smaller but still have significant marketable value.  It also means managing scope for smaller releases so the value can actually be delivered to meet the expectations.  If we make the assumption these two pre-requisites can be handled, then we can also assume faster releases are possible.  Yes, I know, releasing software is expensive, requires other groups, etc.  For now, let’s assume all of those costs are negligible compared to the potential results and see where we end up.
  • ...14 more annotations...
  • team of 8 people work on a project for a year with an anticipated ROI of 100% after 2 years.
  • $1,000,000 (approximately) in 12 months to build the product
  • get $2,000,000 in revenue within the 12 months following release.
  • ROI is calculated as $profit/$invested which in this case is ($2,000,000-$1,000,000)/$1,000,000 or 100%
  • cash expended, which in this case exactly matches the investment since we did all of the investment prior to receiving any return.
  • Let’s assume that scope can be managed so the product can be delivered in two phases, each taking 6 months.
  • each piece of the product is worth about half of the revenue value of the complete product
  • 6 months at an investment of $500,000 to build the first piece
  • 6 more months at an additional cost of $500,000 to complete the second half
  • after 6 months revenue starts to be brought in for the first release
  • the amount of revenue during the first 6 months of release of the first half of the product would be $500,000 ($2,000,000 for full product for 12 months = $500,000 for half product for 6 months).
  • matches the cost for building the second half of the product, so the cash expended is actually only $500,000 for building the product vs. $1,000,000 for building the product in one step.
  • After phase 2 of the product is completed it too starts to bring in revenue.  We now have the complete product, so we can get full value of it during each time period.  In other words, during the next 12 months it will generate $2,000,000 in revenue.  This brings total revenue to $2,500,000 which means our ROI is now 300% (higher profit divided by smaller investment - $1,500,000 profit / $500,000 invested).
  • Month Expense Revenue Cash (Profit) Total Revenue 6 $500,000 $0 -$500,000 $0 12 $500,000 $500,000 -$500,000 $500,000 24 $0 $2,000,000 $1,500,000 $2,500,000
1 - 8 of 8
Showing 20▼ items per page